Modern database and software application development is evolving away from the client-server model toward “cloud”-based processing systems that provide access to data and services via networks such as the Internet. In contrast to prior systems that hosted networked applications on dedicated server hardware, the cloud computing model allows applications to be provided over the network “as a service” supplied by an infrastructure provider.
Although cloud computing platforms can provide substantial benefits to developers and users, certain technical challenges can arise in designing, building and operating database applications based upon such platforms. Database tables that include many-to-many relationships, for example, can pose particular technical challenges in large-scale databases for several reasons. If a user is attempting to create an application that tracks people invited to a meeting or other event, for example, every “event” entry in the database would typically require multiple links to different “invitee” records. That is, any number of events would be linked to any number of invitees, thereby leading to complicated and potentially inter-woven data relationships.
Traditional database management systems often handle many-to-many data relationships by creating “junction tables” to manage the different relationships. These junction tables are effectively separate lists that maintain keys or other data to track the various relationships between the primary tables. Conventional junction tables, however, exhibit several marked disadvantages. At the very least, the junction tables are additional data structures that require processing every time any of the many-to-many resources are modified, thereby requiring substantial computing resources. Moreover, in modern database environments based upon SOAP/REST or similar serial application program interface (API) constructs, client interactions with junction tables can create multiple API calls, thereby increasing computing overhead and presenting additional opportunities for data corruption. To continue the meeting invitee example, creating a new meeting with invitees would require first creating a new event entity to obtain a newly-generated key identifying the new event. The client would then submit the newly-generated key to the appropriate junction records to establish many-to-many relationships between the new event and some number of invitees. In a serialized API such as SOAP or REST, each of these steps would generally require a separate interaction between the client the server. This multi-step process creates the opportunity for data corruption if the first call to obtain the key is successful but ensuing calls to establish junction relationships are unsuccessful.
It is therefore desirable to create processes and systems that can more efficiently process many-to-many relationships without the technical problems currently being experienced in conventional database management systems. It would be further beneficial to streamline database management for serialized interfaces, especially those used in conjunction with multi-tenant or other cloud-based database management systems.